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| veryone agrees that OS/2 \.x was 
■ a flop, but there's little agreement 
about why it flopped. OS/2's 
^ bumpy history has been affected 
by a vast constellation of person- 
alities, strategic decisions, and 

L market forces both seen and in- 
visible. IBM supporters feel that 
Microsoft contributed to OS/2's 
problems first by failing to commit itself 
wholeheartedly to OS/2 application and 
device driver development, and then by 
unilaterally abandoning the operating 
system when it became financially expe- 
'ient to do so. Microsoft partisans, on the 
other hand, claim that IBM doomed OS/2 
by insisting on a 286 version, by linking 
OS/2's destiny with the PS/2, and by in- 
venting a new graphical API instead of 
simply porting Windows to protected 
mode and running it on top of the OS/2 
kernel. There are those who see the last 
six years' events as evidence of sinister 
plots at IBM or Microsoft, and others 
who see the same events as healthy mani- 
festations of a capitalist economy and a 
free market. 

Clearly, there are no simple explana- 
tions for what went wrong, and nearly all 
of the proposed explanations for OS/2's 
problems are subject to various interpre- 
tations. For example, it's certainly fair to 
condemn Microsoft for reneging on its 
commitments to OS/2 developers two 
years ago when it decided to focus on 
Windows development. It's equally fair 
to criticize Microsoft for its decision three 
years earlier to embrace the new Presen- 
tation Manager (PM) API just to gain 
IBM's endorsement, leaving Windows 
developers (both inside and outside Mi- 
rosoft) to twist slowly in the wind. If 
there's a lesson to be learned here, it's 
that developers of any stripe need to be 



wary, because Microsoft never learned 
how to set long-range goals and then stick 
to them through good times and bad. 

In any event, at least one of the 
OS/2 theories is about to be publicly 
tested — the premise that the OS/2 1.x PM 
API was "too big a delta" from the Win- 
dows 2.x API, that developers couldn't 
handle the transition, and that conse- 
quently OS/2 suffered from a lack of pull- 

Despite the move toward a 
32-bit environment, the 
16-bit Windows 3.1 API will 
likely be secure for some time, 
making code portability 
increasingly important. 



through demand generated by hypotheti- 
cal killer applications. 

The whole scenario is about to be 
played out again for 32-bit apps, only the 
playing field is somewhat more level. The 
stable retail version of OS/2 2.0, along 
with a complete set of development tools, 
is already in the hands of tens of thou- 
sands of developers, some of whom have 
been subsidized by IBM to the tune of 
millions of dollars to generate shrink- 
wrapped OS/2 applications. OS/2 2.0 is 
being pitted against Microsoft's NT (New 
Technology) operating system and its 
WIN32 API, which first reached selected 
developers in fall 1991 and became 
broadly available to programmers in July 
1992. The results of the test will be easy 
to evaluate. If, in spite of OS/2 2.0's head 
start, IBM feels obligated to add WIN32 



support to a subsequent version of OS/2 
in order to maintain the system's viabil- 
ity, we will know that the API issue was 
in fact a crucial one. 

WIN16, WIN32, and WIN32S The whole 
concept of the WIN32 API has caused 
tremendous confusion among industry 
columnists and observers. Traditionally, 
the gold standard for a personal com- 
puter operating system API has been a 
particular delivered version of that oper- 
ating system, that is, what it does, rather 
than the documentation (which was often 
incomplete, severely delayed, or down- 
right misleading). When the behavior of 
the operating system and its documenta- 
tion disagreed, the system itself always 
prevailed. 

By contrast, the WIN32 API first ar- 
rived during early 1991 as a specification 
document — unaccompanied (and un- 
tainted) by any attempt at a real-world 
implementation. The specification drove 
the construction of the system, rather 
than being written as an afterthought. It's 
worth taking a few minutes now to clarify 
exactly how WIN32 and its cousin, WIN- 
32S, are related to the Windows 3.x API. 

For convenience, let's refer to the 
Windows 3.1 16-bit API — which includes 
the new functions for DDE (Dynamic 
Data Exchange), drag-and-drop, multi- 
media, common dialogs, and OLE (Ob- 
ject Linking and Embedding) — as the 
WIN16 API. This API reached its pres- 
ent configuration through a process of ac- 
cretion; it is almost laughably asymmetric 
and contains a great many redundant or 
overlapping functions. It seems likely 
that the rich, complex, and wacky WIN16 
API will be secure for several years — if 
for no other reason than that its object- 
oriented successor (called Windows 
Cairo by Microsoft) will be even more 
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subject to many unforseen development 
delays and a lengthy beta test cycle. 

WIN32 is an almost pure 32-bit super- 
set of WIN16. In other words, for essen- 
tially every hardware -independent func- 
tion in WIN 16, there exists a function in 
WIN32 that has the same calling syntax 
and the same semantics. Because WIN32 
is a superset of WIN16, though, WIN32 
also includes many functions that don't 
exist in WIN16. These functions are de- 
signed to position WIN32 as a credible 
competitor to UNIX and the 32-bit 
OS/2 Presentation Manager API; they in- 
clude support for security, networking, 
memory-mapped files, preemptive multi- 
tasking, threads, symmetric multiproc- 
essing, Named Pipes, mailslots, sema- 
phores, and advanced graphics engine 
capabilities such as paths, transforms, 
and Bezier curves. 

The WIN32 API has been imple- 
mented initially on top of Microsoft's NT 



team led by ex-Digital Equipment Corp. 
operating system guru David Cutler, and 
its microkernel architecture is similar to 
Mach (a variant of Unix used on the 
NeXT computer). As I write this, NT/ 
WIN32 is running on Intel 80386/486 and 
MIPS processors, and will soon be avail- 
able for Digital's Alpha processor as well. 
Microsoft has also promised that WIN32 
will be implemented on top of a "future 
version of DOS," though the company 
has been rather vague about the time 
frame. 

Where does WIN32S fit into this pic- 
ture? Apparently, WIN32S is Microsoft's 
attempt to counter widespread fears that 
NT will be too expensive, too powerful, 
and too resource-hungry for the average 
desktop machine. The S in WIN32S 
stands for subset: the WIN32S API con- 
sists of all the WIN32 functions — and 
only the WIN32 functions — that have di- 
rect counterparts in WIN16. WIN32S ap- 
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vantage over full-fledged WIN32 applies 
tions: The same binaries will run on either 
Windows 3.x or NT/WIN32 systems. 

On an NT/WIN32 platform, a 
WIN32S application will not take advan- 
tage of all the NT capabilities, but it will 
benefit from NT's flat memory model, 32- 
bit graphics engine, and improved file 
system. On a Windows 3.x platform, each 
function call by the WIN32S application 
will be trapped by a translation layer in 
a DLL or Virtual Device Driver (VxD) 
and remapped into an ordinary WIN16 
function call. The performance of 
WIN32S applications running under 
Windows 3.x will be throttled by the 
WIN16 graphics engine, but the ability to 
run on Windows 3jc will increase the 
short-term market for WIN32S applica- 
tions dramatically, and should provide 
powerful motivation for developers to 
migrate their Windows programs from 16 
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// WINAPP - WIN16 and WIN32 Portable Application Skeleton 
// Copyright (C) 1992 Ray Duncan 
//PC Magazine 4 Ziff Davis Publishing 



fdefine dim(x) (sizeof(x) / sizeof (x[0] ) ) 

tinclude 'windows. h" 
tinclude "winapp.h" 

HANDLE hlnst; 
KWND hFrame; 

char szShortAppNamet, = "WinApp"; 
char szAppName[] = "Windows Demo App"; 
char szMenuName [] = -WinAppMenu' ,- 
char szlconName.] = "WinAppIcon" ; 



// returns no. of. elements 



// module instance handle 

// handle for frame window 

// short application name 

// long application name 

// name of menu resource 

/ / name of icon resource 



// 

// Table of window messages supported by FrameWndProc ( ) 
// and the functions which correspond to each r 

// 

struct decodeUINT messages! J = { 
WM_PAINT, DoPaint, 
WM_COMMAND, DoCommand, 
WMLDESTROY, DoDestroy, } ; 



tem IDs and their corresponding functions . 



// 

// Table of menubar 

// 

struct decodeUINT menuitemsM s { 
IDM_EXIT, DoMemiExit, 
IDM_ABOUT, DoMenuAbout, ) ; 

// 

// WinMain entry point for this application from Windows. 
// • 

INT API ENTRY WinMain (HANDLE hlnstance, 

HANDLE hPrevInstance, LPSTR lpCmdLine, INT nCmdShow) 



MSG msg; 

hlnst = hlnstance; 

i f ( ! hPrevInstance ) 

if ( ! InitApp (hlnstance) ) 
return ( FALSE) j 



//if first instance, 

// register window class 

// exit if couldn't register 



i f I ! Init Instance (hlnstance, nCmdShow) ) // create this instance's window 
return(FALSE) ,- // exit if create failed 



while(GetMessage(&msg, NULL, 0, 0) ) 



TranslateMessage (limsg) ; 
DispatchMessage(i.msg) ; 



// while message '! = WM_QUIT 



// translate virtual key codes 
// dispatch message to window 



Termlnstance (hlnstance) ; 
return (msg. wParam) ; 



// clean up for this instance 
// return code = WM_QUIT value 



tialization code for this application. 



BOOL Ini t App ( HANDLE hlnstance) 



WNDCLASS wc; 



r frame window class 
W|CS_VREDRAW; 
ineWndProc ; 



// set paramet- 
wc. style = CS_I 
wc . Ipf nWndProc 
wc.cbClsExtra ■ 0; 
wc . cbWndExtra = 0; 
wc. hlnstance = hlnstance,- 
wc.hlcon = Loadlcon (hlnst , szlconName) ,- 
wc.hCursor = LoadCursor (NULL, IDC_ARROW) 
wc . hbrBackground = GetStockObject (WHITE_ 
wc . IpszMenuName = szMenuName; 
wc. IpszClassName = szShortAppName,- 

return(RegisterClass(&wc) ) ; 



// class style 

// class callback function 

// extra per-elass data 

// extra per-window data 

// handle of class owner 

// application icon 
; // default cursor 

BRUSH) j // background color 

// name of menu resource 

// name of window class 

//register class, return status 



// Initlnstance instance initialization code for this application. 

// 

BOOL Initlnstance (HANDLE hlnstance, INT nCmdShow) 



hFrame = CreateWindow) 
szShortAppName , 
s zAppName , 

WS_OVERLAPPEDWIND0W , 
CW_USEDEFAULT, CWJJSEDEFAULT , 
CW_USEDEFAULT, CW_USEDEFAULT , 
NULL, 
NULL, 

hlnstance, 
NULL) ; 

if ( IhFrame) return (FALSE) ; 

ShowWindow (hFrame, nCmdShow) ; 
UpdateWindow(hFrame) ; 
return (TRUE) ; 



> 



/ / create frame window 

// window class name 

// text for title bar 

// window style 

// default position 

// default size 

//no parent window 

// use class default menu 

// window owner 

// unused pointer 

// error, can't create window 

// make frame window visible 

// force WM_ PAINT message 

// return success flag 



Figure 1: This is the source code for the skeleton program that can be compiled for either WIN16 or WIN32. 



// Termlnstance — instance termination code for this application. 

// 

BOOL Termlnstance (HANDLE hinstance} 

< 
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2 of 2 



return (TRUE) ; 



// return success flag 



// FrameWndProc callback function for application frame window. 

// 

LONG FAR API ENTRY FrameWndProc (HWND hWnd, UINT wMsg, UINT w Pa ram, LONG lParaml 
t 

INT i; // scratch variable 

for(i = 0; i < dim (messages ) ; i++) // decode window message and 

{ // run corresponding function 

iflwMsg == messages [ i ] .Code) 

return ( ( 'messages [ i ] .Fxn) (hWnd, wMsg, wParam, lParam) ) j 

) 

// or band off to Windows 
return(DefWindowProc(hWnd, wMsg, wParam, lParam)); 



// DoCommand -- process WM_COMMAND message for frame window by 
// decoding the menubar item with the menuitemsf] array, then 
// running the corresponding function to process the command. 
// 

LONG DoCommandlHWND hWnd, UINT WMsg, UINT wParam, LONG lParam) 
{ 

INT i; // scratch variable 

for(i =8; i < dim(menuitems) ; i++) // decode menu command and 

t // run corresponding function 

if {wParam == menuitems I i] .Code) 

returnf ( 'menuitems [i] .Fxn) (hWnd, wMsg. wParam, lParam) ) ; 

} 

return(DefWindowProc(hwnd, wMsg, wParam, lParam) ) ,- 



// DoDestroy -- process WM_DESTROY message for frame window. 
// 

LONG DoDestroy (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



PostQuitMessage(B) ; 
return (0) ; 



// force WM_QUIT message to 
// terminate the event loop 



'/ DoPaint -- process WM_PAINT message for frame window. 

// 

LONG DoPaint (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



HDC hdc; 
PAINT STRUCT ps; 
RECT rect; 
HFONT hfont; 

hdc = BeginPaint (hWnd, £.ps); // get device context 

GetClientRect (hWnd, &rect); // get client area dimensions 

hfont = CreateFont (-36, 0, 0, 0, 700, // get handle for pretty font 
TRUE, 0, 0, ANSI_CHARSET, 

OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, 
DEFAULT_QUALITY, (FF_MODERN « 4) + DEFAULT_PITCH, 
"Ariel" ) ; 

SelectObject (hdc, hfont); // realize font in DC 

DrawText (hdc, "Hey, Dude!", -1, // paint text in window 

fcrect, DT_CENTER | DT^VC ENTER | DT_SINGLELINE) ; 
EndPaint(hWnd, &ps) ; // release device context 

return (0); // terminate the event loop 



// DoMenuExit 



process File-Exit command from menu bar. 



LONG DoMenuExit (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



SendMessage (hWnd, WM_CLOSE, 0, 0L) ; 
return (0) ; 



// send window close message 
//to shut down the app 



// DoHenuAbout — process File-About command from menu bar. 

// 

LONG DoMenuAbout (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 
{ 

WNDPROC lpProcAbout; // scratch far pointer 

lpProcAbout = MakeProcInstance ( (WNDPROC ) AboutDlgProc , hlnst) ; 
DialogBox (hlnst , "AboutBox" , hWnd, lpProcAbout) ; 
FreeProcInstance (lpProcAbout) ; 
return ( ) ; 



// AboutDlgProc — callback routine for About... dialog 

// 

BOOL FAR API ENTRY AboutDlgProc (HWND hwnd, UINT msg, UINT wParam, LONG lParam) 
( 

if ((msg == WM_COMMAND> && [wParam == IDOK) 1 
EndDialog(hwnd, 0); 

else 

return (FALSE) ; 



bits to 32 bits. 

HOW BIG THE GAP? In the introduction 
to the WIN32 Programmer's Reference 
Manual, Volume I (Microsoft Press, 
1991), Microsoft lists six general goals for 
the WIN32 API. The first two of these 
goals are to provide a 32-bit migration 
path for existing Windows applications 
and to make porting a Windows applica- 
tion to WIN32 as easy as possible. How 
completely has Microsoft achieved these 
goals? The same manual recounts "[The 
Windows 3.1] File Manager contains 
20,000 lines of code; yet within one day, 
it was compiling as a native WIN32 appli- 
cation. Within a week. File Manager 
could execute and display directory list- 
ings." I don't find this to be an incredible 
feat at all; in fact, the admission that it 
took a whole week to get File Manager 
to execute as a WIN32 application makes 
reasonable the assumption that the origi- 
\1 File Manager was very sloppily 
wOded. In my own experience, clean Win- 
dows 3.x application code can be mechan- 
ically edited for WIN32 and will usually 



compile and run on WIN32 the very first 
time. The application code may not work 
entirely correctly the first time, but it will 
do something, and the trouble spots are 
normally quite obvious. 

More importantly, if you study the 
WIN16 and WIN32 APIs carefully before 
writing your application, it's quite feasi- 
ble to compile both WIN16 and WIN32 
binaries from the exact same source code 
base. In fact, if you're willing to sacrifice 
the function calls that are unique to NT/ 
WIN32 — in other words, to settle for a 
WIN32S application instead of a full- 
fledged WIN32 application — you can 
readily hide all the differences between 
the two APIs with conditional compila- 
tion and #defines in the application's 
header files. All this certainly bodes well 
for the early availability of mainstream 
applications on NT/WIN32, and in fact 
Microsoft demonstrated Excel 3.0 run- 
ning as a native WIN32 app before most 
Windows developers had even heard of 
WIN32. Let's take a minute to look at 
some of the differences between WIN16 



and WIN32 that have to be provided for 
in the header file of such a "dual-tar- 
geted" application. 

The most obvious discrepancy be- 
tween the two APIs is that WIN16 was 
built for the Intel 80*86 segment architec- 
ture, while WIN32 was designed for the 
32-bit flat memory model typical of the 
Intel 80386/486 running in paged virtual 
memory mode, the Motorola 680x0 fam- 
ily, and the RISC processors. Thus, the 
segment:offset /br pointers of the WIN 16 
API become 32-bit near offsets in 
WIN32. Microsoft's 32-bit C compiler 
treats the FAR keyword essentially as a 
NOOP, and large-model WIN16 code 
(which doesn't attempt to take advantage 
of "magical" knowledge about the con- 
tents of a far pointer) will usually compile 
without changes for WIN32 — though it 
will execute much more efficiently. Simi- 
larly, application callback functions are 
entered via near calls instead of far pascal 
calls in WIN32. The two calling conven- 
tions can easily be hidden within condi- 
tional #defines and made transparent to 
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WINAPP.H 

Complete Listing 

// 

// WINAPP.H — Header File for Demo Program WINAPP.C 

// 



#i£ ! defined (WIN32) 

#define WIN16 TRUE 
#define WIN31 

♦define INT int 

#define UINT WORD 

♦define APIENTRY PASCAL 

♦define WNDPROC FARPROC 

♦ else 

♦define WIN16 FALSE 
♦endif 



struct decodeUINT { 
UINT Code; 
LONG (*Fxn) (HWND, 



♦define 
♦define 



IDM_EXIT 
IDM_ABOUT 



UINT, UINT, LONG) ; ) 

100 
101 



// structure associates 
/ / messages or menu IDs 
// with a function 



// Function prototypes 

INT APIENTRY WinMain (HANDLE, HANDLE, LPSTR, INT) 

BOOL InitApp (HANDLE) ; 

BOOL Initlnstance (HANDLE, INT); 

BOOL Termlnstance (HANDLE) ; 

LONG FAR APIENTRY FrameWndProc (HWND, UINT, 
BOOL FAR APIENTRY AboutDlgProc (HWND, UINT 
LONG Do Destroy (HWND, UINT, UINT, LONG) ; 
LONG DoPaint(HWND, UINT, UINT, LONG) ; 
LONG DoCommand(HWND, UINT, UINT, LONG); 
LONG DoMenuExi t ( HWND , UINT, UINT, LONG) ; 
LONG DoMenuAbout (HWND, UINT, UINT, LONG) ; 



UINT, LONG) ; 
UINT, LONG) ; 




Figure 2: The #def ine statements in this header file supplement the WINDOWS." header file to mask the 
differences between WIN16 and WIN32. 



a well-behaved application at both com- 
pile time and runtime. 

Another point of divergence between 
WIN 16 and WIN32 is that an integer in 
WIN16 code is, logically enough, 16 bits 
wide, while an integer in WIN32 is 32 bits 
wide. A "short" value, on the other hand, 
remains 16 bits in both systems and a 
"long" is likewise 32 bits in both systems. 
This means you must be very careful 
about using the proper data types for 
handles, logical and device coordinates, 
and other values that are defined as 
signed or unsigned integers in the WIN16 
API, since these are all widened to 32- 
bits in the WIN32 API. For example, I 
often see Windows source code that de- 
clares parameters as WORD when they 
should be unsigned integers (UINT), or 
vice versa. When compiling 16-bit code, 
these data types are equivalent, but im- 
properly specifying a WORD (16 bits) in- 
stead of UINT (32 bits) in WIN32 code 



will yield a compilation error if you're 
lucky, or a crash at execution time if 
you're not. 

The third potential trouble spot — no, 
make that a definite trouble spot — is Win- 



EXETYPE WINDOWS 

STUB ' WINSTUB . EXE 1 

CODE PRELOAD MOVEABLE 

DATA PRELOAD MOVEABLE MULTIPLE 



dows messages. Windows applications 
are event-driven, and the events are rer 
resented as message packets that art 
posted to the application's message 
queue. The application responds to an 
event by reading a message from its 
queue and processing it; if the queue is 
empty, the application yields control of 
the system until a message arrives. A 
WIN16 message packet has four compo- 
nents: a 16-bit handle for the window that 
is to receive the message, a 16-bit mes- 
sage number (the possible values are de- 
fined in the Windows SDK header file as 
names of the form WM_xxxx), a 16-bit 
parameter called wParam, and a 32-bit 
parameter called lParam. In a WIN32 
message packet, the four components 
have the same general usage, but all four 
are the same length: 32-bits. 

Unfortunately, in the WIN16 API, 
certain messages used half of lParam for 
a handle of some type, and the remaining 
half of lParam for other data. Since 
WIN32 handles are 32 bits, such message 
packets obviously must be redefined for 
WIN32, usually by moving the "other" 
data from lParam to the upper or lower 
half of the widened wParam. Once yc 
know about them, differences in message 
formats can be hidden by trivial condi- 
tional #defines in the header file, but the 
mutation of many important message 
packets is the main reason why newly 
ported WIN32 apps often only "sort of 
work" on first try after a clean compile. 

This problem with message packets 
was really completely unnecessary. If 
Microsoft had elected to double the size 
of lParam along with everything else in 




HEAPSIZE 32768 
STACKSIZE 8192 

EXPORTS 

FrameWndProc 
AboutDlgProc 



Figure 3: This is the module definition file for the WINAPP program. 



WINAPP.DEF 

Complete Listing 

NAME WinApp 

DESCRIPTION 'WinApp - Demonstration Windows Application' 
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the message packet, no redefinition of 
■nessage formats would have been 
needed, and one of the few significant ag- 
gravations involved with porting applica- 
tions to WIN32 would have been pre- 
vented. The decision to leave the size of 
lParam at 32-bits in WIN32 was predes- 
tined back when CL386 was being thrown 
together for the first OS/2 2.0 SDK. Ig- 
noring history, Microsoft's languages di- 
vision decreed that there was no need for 
their compiler to support true "longs" 
that were twice the size of a 32-bit integer 
because a 32-bit address or value was big 
enough for any app they could imagine. 
Less than four years later, with the very 
first prerelease version of NT/WIN32 
running on a true 64-bit microprocessor 
(the MIPS R4000), I can't help but won- 
der whether those worthy language de- 
velopers are still employed. 

You've probably been wondering 
when I'd get around to talking about in- 
consistencies between the WIN 16 and 
WIN32 APIs proper. The truth is, the 
glitches you'll encounter in this area will 
be extremely rare. In both WIN 16 and 
WIN32, the same functions do the same 
hings with the same side effects and they 
use the same parameters. If structures are 
passed to or received from the functions, 
the elements of the structures have the 
same names and the same meanings. The 
one API-related circumstance that may 




cause some confu- 
sion occurs when 
the compiler gener- 
ates error messages 
that refer to appar- 
ently nonexistent 
function parame- 
ters. What's almost 
always happening 
in such cases is that 
the function you 
think you're using is 
being remapped by 
a macro in the 
WIN32 header file 
to another (more 
general) function, 
and the parameters 
are being rear- 
ranged. Thus, for ~~~~ 
example, an invocation of CreateWin- 
dow() in your source code is silently re- 
mapped to a call to Create WindowEx(). 

A PORTABLE APP SKELETON We will be 
discussing the WIN16, WIN32, and OS/2 
PM APIs in more detail in upcoming col- 
umns, with particular attention to code 
portability. To give you some initial feel- 
ing for the similarities between the 
WIN16 and WIN32 APIs, however, I've 
written a skeleton application called 
WINAPP that can be compiled without 
changes for Windows 3.1 using Borland 
C++ 3.x or for NT/WIN32 with Micro- 




Hey, Dude! 



Microsoft Windows 
Demo Application 
© 1992 Petit Mai Software 



P 

Demo 



OK 



L_ 



. 



WINAPP. RC 

Complete Listing 




source script for WINAPP. C 



"windows . h" 
"winapp . h" 



inAppIcon ICON winapp. ico 



pMenu MENU 
BEGIN 

POPUP 
BEGIN 

MENUITEM 
MENUITEM 
MENUITEM 

END 

END 



"ScFile" 

"E&xit" , 
SEPARATOR 
"A&bout" , 



IDM_EXIT 



IDM__ABOUT 



AboutBox DIALOG 23 
CAPTION "About 



19, 106, 61 
WinApp ..." 
STYLE DS_MODALFRAME | WS_CAPTION 
BEGIN 

ICON "WinAppIcon" , -1, 12, 9, 
CTEXT "Microsoft Windows", -1 
CTEXT "Demo Application", -1, 



WS_SYSMENU 



WS_VISIBLE 



16, 16, WS^CHILD 

33, 7, 64, 8 
30, 18, 68, 9 

CTEXT "\251 1992 Petit Mai Software", -1, 9, 30, 87, 9 
CONTROL "OK", IDOK, "BUTTON", WS_GROUP, 36, 43, 32, 14 



Figure 4: This is the resource script for the WINAPP program. 



Figure 5: This is a screen shot of the WINAPP program. Can you guess whether 
it's running under Windows 3.x or NT/WIN32? 



soft's CL386. The source code for WIN- 
APP can be found in Figure 1, the header 
file in Figure 2, the module definition file 
in Figure 3, the resource script in Figure 
4, and a screenshot of WINAPP in action 
in Figure 5. All of these source files can 
be downloaded from PC MagNet. Or, if 
you don't have access to PC MagNet, you 
can get the files on-disk by sending a post- 
card with your name, address, and pre- 
ferred floppy disk size to Katherine West, 
Power Programming, PC Magazine, One 
Park Ave., New York, NY 10016. 

WINAPP is just a toy program of the 
"Hello World" genre, but it knows how 
to carry out almost all of the fundamental 
tasks of a Windows application. It pro- 
cesses messages, decodes menu com- 
mands, selects a font, paints in its win- 
dow, and has a dialog box. The 
modularity and maintainability of the 
program is enhanced by use of the same 
table-driven message dispatcher that we 
previously saw in the DLGDEMO and 
SYSMON programs. You can use the 
WINAPP program as a starting point for 
much more elaborate applications that 
will run happily in either 16-bit or 32-bit 
mode; I've been doing it for quite a few 
months now, and you'll see some of the 
results in the next few issues. 

THE IN-BOX Please send your ques- 
tions, comments, and suggestions to me 
at any of these electronic mail addresses: 
PC MagNet: 72241,52 
MCI Mail: rduncan 
BIX: rduncan 

INTERNET: duncan@csmcmvax.bitnet □ 
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